@jlurien I have an issue here because in location-retrieval we do not have unknown/UNKNOWN.
We have either

{
  "status": 400,
  "code": "LOCATION_RETRIEVAL.MAXAGE_INVALID_ARGUMENT",
  "message": "maxAge threshold cannot be satisfied"
}

or

{
  "status": 404,
  "code": "NOT_FOUND",
  "message": "The specified resource is not found"
}

400 seems a better fit because it specifically points to maxAge. And it applies for all maxAge values, not only 0.
If maxAge was not provided in the request (any age is acceptible), but the system still cannot find a location, 404 can be used.

Thanks @alpaycetin74
Works for me and I can update the documentation accordingly.
If not able to provide require freshness (maxAge filled) --> 400 + code LOCATION_RETRIEVAL.MAXAGE_INVALID_ARGUMENT
If not able to provide any location for a request without maxAge --> 404

Right, I didn't realize that.
Regarding errors, to me 400 is for cases when the provided input does not comply with the schema or some constraint that should be known by the client, independently of the device. It could fit for cases where some implementation does not support maxAge=0 for any user (it is still pending how to provide information about limits of the implementation to the client). But for cases where the maxAge cannot be satisfied for a specific device or at a specific moment, I think it is more of a 404 or even 422 (the entity combining device and maxAge is not processable by the system).

These RESTful interpretations of HTTP statuses are very subtle anyway.

For (2) I think 404 is more natural, the (3) is more about the combination of device + maxAge at a given time

(1)If maxAge input does not fit the pattern (like 5fr/"3) --> 400
(2)If not able to locate the mobile --> 404 with code LOCATION_RETRIEVAL.DEVICE_NOT_FOUND
(3)If not able to provide expected freshness --> 422 with a code LOCATION_RETRIEVAL.UNABLE_TO_FULFILL_MAX_AGE

cc @javier-carrocalabor

Another difference with location-verification is that in this case we cannot return a lastLocationTime indicating how old is the more recent location

hello @bigludo7 ,

• is maxAge parameter absent in case (2) ?
• in case (3), there is a maxAge parameter for sure, and it can also be 0, am I right ?
  Thank you.

Hello @alpaycetin74

is maxAge parameter absent in case (2) ?
Humm.. It is fair to assume that yes.

in case (3), there is a maxAge parameter for sure, and it can also be 0, am I right ?
Yes - no doubt for this one !

Thanks @bigludo7 ,
if I may summarize my view:

For location retrieval,
(1) Obviously a client error, 400 is appropriate.
It is possible to advise LOCATION_RETRIEVAL.MAXAGE_INVALID_ARGUMENT, but the implementer may not have full control over error messages created in case of syntactic errors - those may be created by software libraries.
(2) No location available, even if maxAge is absent (infinite).
404 with code LOCATION_RETRIEVAL.DEVICE_NOT_FOUND is appropriate.
(3) maxAge condition (including 0) cannot be satisfied.
422 with code LOCATION_RETRIEVAL.UNABLE_TO_FULFILL_MAX_AGE is appropriate.

For location verification,
(1) same
(2) UNKNOWN without lastLocationTime
(3) UNKNOWN, may have lastLocationTime if system has it.
Thank you

This line has to be modified in any case, as the API cannot response "unknown"

The text should refer to 404 instead of 400, I think.
I find 400 appropriate only if the maxAge is syntactically wrong.

The schema needs to be renamed to RetrieveLocationUnprocessableEntity422

The schema needs to be renamed to RetrieveLocationUnprocessableEntity422

What is "maxDate"? If you mean "maxAge" I wouldn't include the formula, as it is confusing: current time - location time > 0 ==> current time > location time, which is always true.